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(57) Abstract: A system and method for multicasting data over a network includes a director, a hierarchy of participant managers, 
and a turnstile installed at each participant to which the data is multicasted. Content providers provide information associated with 
an event to the director. The director overseas the delivery of the event to a participant. In particular, the director allocates and 
provides a ticket to the event to the participant. The participant acquires the ticket, either directly or indirectly from the director. 
When the participant attempts to access the event, the locally installed turnstile authenticates the ticket thereby gating access to the 
event. The turnstile also provides delivery statistics associated with the delivery of the event to the director via the hierarchy of 
participant managers. 
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SYSTEM AND METHOD FOR MULTICASTING DATA 



Background 

Field of the Invention 

The present invention relates generally to network communications systems 
and more particularly to managing data multicasting over a network where 
5 recipients of that data can be authorized, authenticated, and billed for receiving that 
data. 

Discussion of the Related Art 

Today's user of a network communication system is demanding that large 
amounts of content (z\e data, voice, images, video, etc.) be delivered to their 

10 network receiving device (e.g., computer, set-top, PDA, cellular phone, etc.) in 
real-time. As network communications systems, particularly the Internet, become 
a ubiquitous communication link among users worldwide, more applications are 
looking to this link to deliver content to multiple users simultaneously in the form 
of a network broadcast. In the network broadcast, multiple users receive similar or 

15 identical content from a single source virtually simultaneously. 

One conventional mechanism for delivering content oyer a network 
communication system is referred to as a unicast. In unicasting, a source of the 
content sends the content to each of the users or "recipients" of the content within 
the network communication system. This is referred to as a "one to one" delivery 
20 of content. Unicasting to N recipients involves sending N copies of the content 
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over the network communication system, one copy to each recipient. For large 
numbers of recipients, these multiple copies have a deleterious effect on the 
performance of the network communication system, particularly for content 
requiring a high amount of bandwidth for delivery video streams). 

5 Another mechanism for delivering content over the network 

communication system is to simply broadcast the content to every user on the< 
network communication system regardless of whether the user desires to receive 
the content or not. This is referred to as a "one to all" delivery of content. With 
broadcasting, one copy of the content, addressed to every user on the network, is 
1 0 transmitted over the network communication system. While broadcasting reduces 
the amount of the network bandwidth consumed by the delivery of the content, not 
all users desire or should receive the content Furthermore, the source of the 
content has no mechanism for determining which of the recipients received the 
content. 

1 5 Another mechanism for delivering content over the network 

communication system is a referred to as a multicast. In multicasting, the source 
of the content sends one copy of the content addressed to only those recipients who 
should receive the content- This is referred to as a "one to many" delivery of 
content With this form of delivery, the content is replicated at key points in the 

20 network communication system so that each recipient receives the content quickly 
and efficiently without the problems associated with other forms of delivery. 
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However, conventional delivery of content via multicast still has many 
problems that heretofore have hindered its adoption as a content delivery standard. 
One problem associated with multicasting not found with unicasting is that the 
originator of the content does not know which, if any, of the recipients actually 
5 received the content la contrast, with unicasts, the originator can measure 
network bandwidth and determine the recipients of the content. However, with 
unicasts, the number of recipients is bound by the resources available to support 
the replication of each content stream. 

Another problem with multicasting is that the originator of the multicast 
10 content is unable to measure the amount and quality of the content delivered to any 
particular recipient. Originators that bill recipients based on bandwidth usage are 
reluctant to provide a service for which they cannot effectively measure that usage. 
Furthermore, in network communication systems employing unicasts, there is a 
direct relationship between the number of servers in the system and the number of 
1 5 recipients able to be serviced by the system. Thus, billing for those services is 
relatively straightforward. This same relationship is not available in a network 
communication system employing multicasts. 

What is needed is an improved system and method for multicasting content 
in a network communication system. 

20 Summary of the Invention 

The present invention is directed toward a system and method for 
multicasting data in a network communication system. In particular, the present 
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invention provides a system and method for managing, measuring, and controlling 
how information is delivered across a multicast-enabled network communication 
system (/. e. , "multicast environment"). The present invention is described in terms 
of a stadium analogy where participants receive an "event," or the information, 

5 from a "stadium " Prior to entering the stadium, participants present a 'ticket" at a 
"turnstile." The turnstile prevents those participants without a proper ticket from 
entering the event The turnstile also provides information via a hierarchy of 
participant managers to the "director" of the event regarding when the participant 
entered the event, when the participant exited the event, and/or information 

10 regarding the delivery of the event to the participant The hierarchy of participant 
managers aggregates this information thereby providing an indication of the 
stadium's "use" to the director. This aggregated information may be provided to 
an event sponsor a content provider) for purposes of billing, advertising, 
and/or determining levels of participation in the event and among events. 

1 5 One feature of the present invention is that the hierarchy of participant 

managers is self-organizing and self-healing. Each of the participant managers 
automatically locates its position in the hierarchy based on a predetermined level. 
The participant manager multicasts its level to other participant managers, some of 
which respond and identify their own level. Based on the responses, the 

20 participant manager determines to which of the other participant managers it 
should be attached. If, at any point, one of the participant managers fails, 
participant managers attached beneath the failing participant manager are able to 
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relocate themselves within the hierarchy to prevent "blackouts" among particular 
participants. 

Another feature of the present invention is that the participant managers 
preferably organize themselves on a geographical basis with the lowest level 
5 participant managers attached to participants in close physical proximity thereto. 
Higher level participant managers are similarly attached to the lower levei 
participant managers. In this manner, each subsequently higher level of participant 
manager represents a greater number of participants in a larger geographic area 
until the highest level of participant manager represents all the participants of the 
1 0 event This feature allows the director and/or the content providers to determine 
the geographic areas of the participants participating in a particular event The 
enables the director to properly allocate resources among the geographic areas for 
future events. This also provides opportunities for targeting advertisements to the 
participants on a geographic basis. 

15 Still another feature of the present invention collects demographic 

information associated with the participant in exchange the ticket. Preferably, this 
demographic information is incorporated into the ticket so that during the event, 
the director and/or the content provider can identify and classify any of the 
participants or groups of participants receiving in the event. The demographic 

20 information also provides opportunities for targeting advertisements to the 
participants on a demographic basis. 
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Yet still another feature of the present invention presents statistics 
associated with the delivery of the event to participants in a tree structure in a 
graphic user interface. The tree structure includes the director at the root, various 
levels of participant managers forming the branches, and participants at the leaves. 
5 Each level of participant managers corresponds to a level indicator in the tree 
structure. Each level indicator identifies the participant manager and provides 
information about the participant managers or participant connected beneath it in 
the tree structure. Preferably, this information represents aggregate delivery 
statistics pertaining to all of the participants connected beneath it in the tree 
10 structure. A user is able to navigate the tree structure and "drill down" to 
particular levels to access these aggregate delivery statistics associated with a 
particular participant manager or the delivery statistics and/or demographic 
information pertaining to an individual participant. 

These and other features and advantages of the present invention will 
1 5 become apparent from the following drawings and description. 

Brief Description of the Drawings 

The present invention is described with reference to the accompanying 
drawings. In the drawings, like reference numbers indicate identical or 
functionally similar elements. Additionally, the left-most digit(s) of a reference 
20 number identifies the drawing in which the reference number first appears. 

FIG. 1 illustrates a multicast environment according to the present 
invention. 
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FIG. 2 illustrates a stadium analogy useful for describing the present 
invention. 

FIG. 3 illustrates an exemplary hierarchy of participant managers. 

FIG. 4 illustrates a director according to a preferred embodiment of the 
5 present invention. 

FIG. 5 illustrates a graphical user interface for monitoring delivery of an 

event. 

FIG. 6 illustrates an operation of a participant attempting to access an event 
according to one embodiment of the present invention. 

10 FIG. 7 illustrates a stadium according to one embodiment of the present 

invention. 

FIG. 8 illustrates a relationship among participants, participant managers, 
and content providers. 

FIG. 9 illustrates a cast transaction according to one embodiment of the 
15 present invention. 

FIG. 10 illustrates an operation of an autodiscovery algorithm from the 
perspective of a new participant manager according to a preferred embodiment of 
the present invention. 

FIG. 1 1 illustrates an operation of the present invention from a perspective 
20 of a participant. 
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FIG. 12 illustrates an operation of the present invention from a perspective 
of a turnstile. 

FIG. 13 illustrates an operation of the present invention from a perspective 
of participant manager. 

5 FIG. 14 illustrates an operation of the present invention from a perspective 

of director server. 

FIG. 15 illustrates an operation of the present invention from a perspective 
of director server gathering delivery statistics from a particular participant 
manager. 

10 FIG. 16 illustrates an operation of the present invention from a perspective 

of director client. 

FIG. 17 illustrates an operation of an autodiscovery algorithm from the 
perspective of an existing participant manager according to a preferred 
embodiment of the present invention. 

1 5 Detailed Description of the Preferred Embodiments 

The present invention is directed toward a system and method for 
multicasting data in a network communication system. In particular, the present 
invention provides a system and method for managing, measuring, and controlling 
how information is delivered across a multicast-enabled network communication 
20 system (i.e. , "multicast environment")^ While the present invention is described 
herein using a "stadium analogy," it will be apparent from the following discussion 
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how the present invention contemplates delivery of any form of data to multiple 
recipients in a multicast environment in an authenticated, reliable and controlled 
manner. 

System Overview 

5 FIG. 1 illustrates a multicast environment 100 according to the present 

invention, includes a multicast-enabled network communication system 105. 
Multicast environment 100 may include at least one content provider 110 
(illustrated as a content provider 1 10A and a content provider 1 10B), a plurality of 
participants 120 (illustrated as a participant 120A, a participant 120B, and a 

10 participant 120C), one or more participant managers 130 (illustrated as a 

participant manager 130A and a participant manager 130B), a director 140 and/or a 
ticket provider 150. 

FIG. 2 illustrates a stadium analogy 200 useful for describing multicast 
environment 1 00, particularly for describing its use to deliver an event 220. 
15 Content providers 1 10 provide event 220 to stadium 210 for delivery to 

participants 120. Participants 120 acquire a ticket 240 to event 220 from ticket 
provider 150. Participants 120 present ticket 240 at a turnstile 230 to enter stadium 
210 whereby they begin participating in event 220. 

Participant managers 130 located at strategic points within network 
20 communication system 1 05 manage the delivery of event 220 to the participants 
120. Director 140 oversees the delivery of event 220 by supervising participant 
managers 130, ensuring that event 220 is delivered to each participant 120. 
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Using turnstiles 230, participant managers 130 can determine which and 
how many of participants 120 participated in event 220 and can determine the 
duration of that participation. This information is collected and aggregated by 
participant managers 1 30 and maintained by director 140 for billing purposes or 
5 for evaluating demographic information associated with participants 120 of event 
220. Each of these aspects of multicast environment 100 is described in further 
detail below. 

Multicast Environment 

Multicast environment 100 includes network communication system 105 
10 that is configured for multicasting content (/.e. events 220) from a single source 
(z.e., stadium 210) to multiple recipients (z.e., participants 120). In one 
embodiment of the present invention, multicast environment 100 operates on the 
Internet using well-established protocols, including various protocols for 
communicating via one or more wireless connections. In an alternate embodiment 
15 of the present invention, multicast environment 100 operates on an entity's intranet 
using similar well-established network protocols. This entity may include, but is 
not limited to a company, a government, a government agency, an organization or 
any other entity that operates a private intranet or similar communication network. 

Event 

20 According to the present invention, event 220 is a time-sensitive delivery of 

an information stream to multiple recipients. Preferably, event 220 is intended to 
arrive virtually simultaneously at each participant 120. Event 220 may comprise a 
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continuous information stream such as a video stream, an audio stream, or other 
form of continuous data stream, that is either "live" or pre-recorded. The 
information stream may also comprise one or more data files such as an image file, 
an application program, an application program update, a database, or other form 

5 of data file destined to multiple recipients. The information stream may also 

comprise a conferencing information stream such as video teleconferencing, audio 
teleconferencing, collaborative working environments or other form of 
conferencing information stream; a news information stream such as various wire 
service information streams including UPI, API, etc.; equity and/or commodity 

10 ticker information streams such as NYSE, NASDAQ, CBOE, etc.; and a gaming 
information stream for interactive multi-player network games. 

Content Providers 

Content providers 110 provide the content that is to be delivered to 
participants 120 in multicast environment 100, preferably from stadium 210 in the 

1 5 form of event 220. More particularly, content providers 110 provide an 

information stream that is to be multicasted to participants 120. In general, content 
providers 110 may provide any form of information stream that may benefit from 
delivery in a multicast environment 110, particularly where identical or similar 
information is to be simultaneously (or virtually simultaneously) delivered to 

20 multiple participants 120. 

Content providers 110 may include commercial webcasting companies as 
well as enterprises. Examples of commercial company information streams 
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include, but are not limited to, financial and technical community briefings and 
conferences, sporting events, music concerts, movie premieres, news services and 
on-line learning. Examples of enterprise information streams include, but are not 
limited to, all-hands briefings and announcements, management communications, 
5 employee training, and customer service communications. 

According to a preferred embodiment of the present invention, content 
providers 110 establish a web page for the information stream that can be accessed 
via a web browser. Preferably, from the perspective of participants 120, the 
information stream is accessed as event 220 through stadium 210. Content 

10 provider 110 provides director 140 with an address (preferably a URL address) for 
the web page associated with event 220 discussed above to accomplish this aspect 
of the invention. Director 140 reformats this URL address as a Stadium URL 
address ("SURL") for operation with multicast environment 100 and returns the 
SURL to content provider 1 10 to be included in the web page. Further aspects of 

15 the interaction between content provider 110 and multicast environment 100 are 
discussed in further detail below. 

Stadium 

FIG. 7 illustrates stadium 210 according to one embodiment of the present 
invention. According to the present invention, stadium 210 is a virtual stadium. 
20 Stadium 210 may include one or more sections 710 (illustrated as a first section 
710A, a second section 710B, a third section 710C, and a fourth section 710D). In 
one embodiment of the present invention, each section 710 is associated with a 
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different event 220 being offered in stadium 210 at that particular time. In an 

i 

alternate embodiment of the present invention, each section 710 is associated with 
a different class of service associated with the delivery of a particular event 220. 
Such classes of service may include, for example, encoding data at different bit 
5 rates for delivery via a cable modem so that a lower class of service might receive 
data at 56kbps and a higher class of service might receive data at 300kbps. Other 
forms of discriminating classes of service are available as would be apparent 

Events 220 offered in stadium 210 offered at any particular time may all 
originate from a particular content provider 110. Alternately, events 220 offered in 
10 stadium 210 may originate from different content providers 1 10. 

The present invention also contemplates multiple stadiums 210 each 
offering multiple events 220 or multiple classes of service for a particular event 
220 at any particular time. For example, one stadium 210 may offer various live 
baseball games, while another stadium 210 may offer various inspirational 
1 5 speakers. Events offered via various stadiums 210 and within particular stadiums 
are numerous and may be organized in various manners as would be apparent. 

Participants 

Participants 120 are those users that receive event 220 (z.e., recipients of the 
information stream) via network communication system 105. Participants 120 may 
20 be consumers in the event that content provider 110 is a commercial company, or 
employees in the event that content provider 1 10 is an enterprise. 
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Preferably, participants 120 perceive that they receive event 220 from 
stadium 210. In a preferred embodiment of the present invention, participants 120, 
upon accessing stadium 210 to participate in event 220, are redirected to content 
provider 1 10, or more particularly, to a multicast-enabled URL address from which 
5 event 220 is delivered. In some embodiments of the present invention, content 
providers 110 provide event 220 to stadium 210 a priori, and stadium 210 
subsequently directs participants 120 to the multicast enabled URL address. 

Participants 120 generally receive the information stream via a suitable 
receiving device such as, but not limited to, a computer workstation, a PDA, a 

10 memory device (eg., an MP3 player, a memory stick, etc.), a cellular telephone, a 
set-top box, or any other form of electronic device capable of receiving 
information from network communication system 105, including those employing 
one or more wireless connections to network communication system 105. In one 
embodiment of the present invention, the receiving device includes a web browser 

1 5 that operates in conjunction with an event Tenderer such as a media player (e.g. , 
Real Player™, Microsoft Windows' Media Player™, etc.) to render event 220 for 
use by participant 120. In an alternate embodiment, the event renderer is delivered 
prior to or as part of event 220. For example, if event 220 comprises an 
application program upgrade, event 220 may also include or be accompanied by a 

20 self-installing event renderer that installs the upgrade on participants* receiving 

device. The interaction between participants 120 and multicast environment 100 is 
discussed in further detail below. 
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Participant Managers 

Participants 120 are managed and organized in multicast environment 100 
by one or more participant managers 130 located at various strategic points within 
the network communication system. Preferably, participant managers 130 are 
5 organized within multicast environment 100 in a hierarchy 300 as illustrated in 
FIG. 3. Hierarchy 300 includes one or more levels of participant managers 130. 
Each level may organize and manage one or more lower levels of participant 
managers 130 and/or one or more participants 120. Preferably, multicast 
environment 100 includes up to 255 levels of participant managers 130 with any 
10 number of participant managers 130 resident at each level. Other embodiments 
include fewer or more levels of participant managers 130 as would be apparent 
Hierarchy 300 forms a tree topology with participants 120 at the "leaves," various 
levels of participant managers 130 forming the "branches" and director 140 
forming the "root." 

1 5 Hierarchy 300 of participant managers 130 manage and organize 

participants 120 in multicast environment 100 by directing network commands and 
control information downward from director 140, through the levels of participant 
managers 130, and ultimately to participants 120. Likewise, information 
associated with the delivery of the event is directed upward from participants 120, 

20 through the levels of participant managers 130, which aggregate the information, to 
director 140 which monitors the delivery of the event. This process is discussed in 
further detail below. 
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In one embodiment of the present invention, hierarchy 300 is formed on a 
geographic basis. As illustrated in FIG. 3, hierarchy 300 includes a regional (e.g., 
West Coast) participant manager 310 that manages and organizes three state 
participant managers 320 within that region, namely a California participant 
5 manager 320A, an Oregon participant manager 320B, and a Washington 
participant manager 320C. Each of these state participant managers 320 may 
include one or more district participant managers 330. As illustrated in FIG. 3, 
California participant manager 320 includes at least a Central California participant 
manager 330. Other district participant managers 330 may be included but are not 
1 0 iUustrated for purposes of clarity. 

Each district participant manager 330 may further include one or more 
locality participant managers 340. As illustrated in FIG. 3, Central California 
participant manager 330 includes a San Francisco participant manager 340A, a San 
Jose participant manager 340B, and an Oakland participant manager 340C. 

1 5 Various additional lower levels of granularity may be included in hierarchy 300. 
However, in this illustration, each locality participant manager includes one or 
more participants 120. As illustrated in FIG. 3, San Francisco participant manager 
340A includes a participant 350A, a participant 350B, and a participant 350C; San 
Jose participant manager 340B includes a participant 350D; and Oakland 

20 participant manager 340C includes a participant 350E and a participant 350F. 

It should be understood that the terms "regional," "state," "district," and 
"locality* are used herein for purposes of illustration and not as specifying any 
particular method of organizing participants 120. As would be apparent, various 
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mechanisms for organising participants 120 and participant managers 130 into 
hierarchy 300 are available and might be used in various circumstances. 

Preferably, participant managers 130 are located at various strategic points 
within the network communication system 105. When network communication 
5 system 105 includes the Internet, these strategic locations may include various 
points-of-presence ("POPs") within the Internet, preferably located near 
participants 120. Alternately, when network communication system 105 includes 
an Intranet, these strategic locations may include various subnets, departments, 
buildings, or geographic locations within the intranet. Of course these locations 
10 may also include a combination of strategic points within various intranets 
operating within the overall framework of the Internet as would be apparent. 

Director 

Preferably, each stadium 210 in multicast environment 100 is associated 
with a director 140. However, in alternate embodiments of the present invention, 

15 director 140 may be associated with several stadiums 210. Director 140 oversees 
and manages the delivery of event 220 from stadium 210 to participants 120. 
Director 140 also provisions tickets 240 for events 220 in stadium 210. In a 
preferred embodiment of the present invention, director 140 is comprised of two 
components: a director server 410 and a director client 420 as illustrated in FIG. 4. 

20 Each of these is now described in further detail. 
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Director Client 

According to a preferred embodiment of the present invention, director 
client 420 is one component of director 140. Director client 420 preferably 
comprises a web-based monitoring tool that provides dynamic, real-time views of 
5 the delivery of event 220 within multicast environment 1 00. In particular, director 
client 420 provides information regarding participants 120 as well as delivery 
statistics associated with participants 120 at various levels within hierarchy 300. 
Director client 420 also provides interactive control over participant managers 130 
and participants 120 within hierarchy 300, including the ability to delete a 
1 0 particular participant 120 from event 220. 

Director client 420 also operates as an interface to create event 220, edit 
event 220, remove event 220 and other management operations associated with 
event 220. Preferably, either content provider 1 10 or a system operator may access 
director client 420 to perform these operations. 

15 FIG. 5 illustrates an exemplary graphical user interface ("GUI") 500 

associated with director client 420 for providing information regarding the delivery 
of event 220. More particularly, FIG. 5 illustrates a GUI 500 that represents 
various performance and information aspects of the delivery of event 220 (referred 
to herein as delivery statistics) to one or more participants 120 arranged in a left 

20 GUI portion 5 1 0 and a right GUI portion 570. 

Left GUI portion 510 includes a GUI tree structure 515 corresponding to 
hierarchy 300. GUI tree structure 515 represents the various levels of hierarchy 
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300 in a familiar "directory tree structure" such as that employed in various "file 
manager" applications. In this example, GUI tree structure 515 corresponds to 
hierarchy 300 for West Coast participant manager 310. Thus, a first level structure 
indicator 520A corresponds to California participant manager 320A; a first level 

5 structure indicator 520B corresponds to Oregon participant manager 320B; and 
first level structure indicator 520C corresponds to Washington participant manager 
320C. Each first level structure indicator 520 may include information 521 (such 
as information 521 A) that identifies its corresponding participant manager 130 
and/or that summarizes aggregate delivery statistics corresponding to participants 

10 managers 130 attached beneath it 

Each first level structure indicator 520 may include one or more second 
level structure indicators 525. For example, a second level structure indicator 
525A corresponds to Central California participant manager 330. Each second 
level structure indicator 525 may include information 526 that identifies its 
15 corresponding participant manager 130 and/or that summarizes aggregate delivery 
statistics corresponding to participants managers 130 attached beneath it. 

Likewise, each second level structure indicator 525 may include one or 
more third level structure indicators 530. For example, second level structure 
indicator 525A includes a third level structure indicator 530A corresponding to San 
20 Jose participant manager 340BA, a third level structure indicator 530B 

corresponding to San Francisco participant manager 340A, and a third level 
structure indicator 530C corresponding to Oakland participant manager 340C. 
Again, each third level structure indicator may include information 531 that 
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identifies its corresponding participant manager 130 and/or that summarizes 
aggregate delivery statistics corresponding to participant managers 130 attached 
beneath it. 

Although described above as being associated with participant managers 
5 130, any of structure indicators 520, 525, 530 may correspond to a particular 
participant 120. Likewise, each of structure indicators 520, 525, 530 may include 
information that identifies its corresponding participant 120 and/or that provides 
delivery statistics corresponding to participant 120. 

As illustrated in FIG. 5, third level structure indicator 530B and its 
10 information 53 IB are taghligbted. Preferably, when any of particular structure 
indicators 520, 525, 530 are highlighted in left GUI portion 510, information 
associated with the corresponding participant manager 130 is presented in right 
GUI portion 570. Thus, as illustrated in FIG. 5, right GUI portion 570 includes 
information corresponding to San Francisco participant manager 340A. 

15 In a preferred embodiment of the present invention, right GUI portion 570 

provides information associated with participants 120 organized below the 
corresponding participant manager 130 associated with the highlighted structure 
indicator in left GUI portion 510. In this example, right GUI portion 570 includes 
information corresponding to participants 3 50 A, 35 0B and 350C organized below 

20 San Francisco participant manager 340A. If structure indicator 525 A were 
highlighted in FIG. 5, right GUI portion 570 would include information 
corresponding to participants 350A-F. 
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In a preferred embodiment of the present invention, the information 
corresponding to participants 120 displayed in right GUI portion 570 includes a 
ticket ID 540 and a duration 545. Ticket ID 540 corresponds to an identification 
number of ticket 240 granted to a particular participant 120 whereby the particular 

5 participant was granted access to event 220 as will be discussed in further detail. 
Duration 545 corresponds to an amount of time that the particular participant 120 
participated in the event received the information stream). In some 
embodiments of the present invention, duration 545 may correspond to an amount 
of data (expressed in bytes or other suitable measure of data) delivered to the 

10 particular participant 120. Other information corresponding to participants 120 
may be included as would be apparent. 

As illustrated in FIG. 5, a particular ticket ID 550 is highlighted. In a 
preferred embodiment of the present invention, further information 565 is 
displayed in right GUI portion 570, for highlighted ticket ID's such as ticket ID 

15 550. In one embodiment of the present invention, further information 565 includes 
demographic data 560 associated with the particular participant 120. This 
demographic information may include name, address, age, gender, household 
income, occupation, telephone number, and various other demographic information 
as would be apparent. In a preferred embodiment of the present invention, the 

20 particular participant 120, in exchange for ticket 240 to event 220, may have 
provided this demographic information. 

System operators and content providers 1 10 may access director client 420 
to monitor the delivery of event 220. Likewise, system operators and -content 
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providers 110 may access director client 420 after delivery of event 220 to conduct 
pre-processing or post-processing on the delivery of event 220. 

In a preferred embodiment of the present invention, director client 420 is 
used to determine demographic information associated with the delivery of a 
5 particular event 220. This demographic information may be used to target a direct 
advertising campaign or provide special offers to a subset of participants 120 on a 
demographic and/or geographic basis. Additional aspects of this embodiment are 
described in further detail below. 

Director Server 

10 Director server 410 provides various organizational and management 

functions of director 140, namely provisioning event 220, controlling delivery of 
event 220, logging delivery of event 220, and reporting delivery of event 220. 
Each of these are now described in further detail. 

Event Provisioning 

15 Director server 410 provides management tools to provision stadium 210 

for events 220. Provisioning stadium 210 for events includes allocating, 
dispensing, and tracking tickets 240. In this regard, director server 410 may 
determine a maximum number of tickets 240 that can be dispensed by a particular 
content provider 110. This controls an amount of access the particular content 

20 provider 1 10 has to stadium 210. Director server 410 may also determine a 

maximum number of tickets 240 that can be dispensed for a particular event 220 in 
stadium 210. This controls a number of participants 120 to the particular event 220 
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and limits their attendant system requirements imposed on network communication 
system 105 (e.g* 9 server capacity, bandwidth, etc.). Director server 140 may also 
determine a maximum number of tickets 240 that can be dispensed for any 
particular point in time per participant manager 130. This controls an amount of 

5 participants 120 accessing a particular point of presence in network 

communication system 105 to again limit the burden imposed on that particular 
point of presence (e.g. 9 server capacity, number of modems, network bandwidth, 
etc.). Director server 140 may also determine a maximum number of tickets 240 
that may be dispensed to participants 120 organized below any particular 

10 participant manager 130. By setting this maximum number to zero for some 

participant managers 130 and to a non-zero number for other participant managers 
130, the director server 410 may control a geographic region (e.g. 9 a country, a 
state, a county, a city, etc.) in which participants 120 can access event 220. 

In a preferred embodiment of the present invention, director server 410 
1 5 maintains a database of all tickets 240 that have been dispensed in multicast 
environment 100 and used within stadium 210. This database may include 
information associated with the particular participant 120 to which each ticket 240 
is dispensed. These tickets 240 are maintained on a per event as well as a per 
participant manager for purposes of planning and provisioning addition resources 
20 in multicast environment 1 00. 
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Controlling Delivery of Event 

Director server 410 also controls delivery of event 220 using a delivery 
method referred to as the SURL. The SURL is generated by director server 410 
and resides on the web page provided by content provider 1 10 for a particular 
5 event 220. The SURL is implemented using a Java Applet, Servlet, HTML, or a 
combination of any of these or similar code scripting languages. 

FIG. 6 illustrates an operation of this delivery method as it delivers the 
particular event 220 to participant 120. In a step 610, participant 120 invokes the 
SURL by attempting to access the particular event on the web page. In a step 620, 

10 the delivery method determines whether participant 120 has turnstile 230. In a 
preferred embodiment of the present invention, the delivery method determines 
whether a particular directory is present on the receiving device of participant 120 
and that files associated with turnstile 230 reside therein. Other mechanisms for 
determining whether participant 120 has turnstile 230 are available as would be 

15 apparent. If participant 120 has a turnstile, processing continues at a step 635; 
otherwise, in a step 630, turnstile 240 is downloaded and installed at participant 
120. 

In step 635, turnstile 230 is invoked. In a step 640, turnstile 230 determines 
whether participant 120 has ticket 240 corresponding to the particular event 220. 
20 In a preferred embodiment of the present invention, turnstile 230 determines 
whether a registry (such as a Windows™ registry) includes ticket 240 
corresponding to the particular event 220. In addition, turnstile 230 authenticates 
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ticket 240 to determine whether ticket 240 is a valid one. If participant 120 has 
ticket 240 corresponding to the particular event 220, processing continues at a step 
660. Otherwise, if participant 120 does not have ticket 240, in a step 650, turnstile 
230 directs participant 120 to an appropriate location where ticket 240 can be 
5 acquired such as director server 410, content provider 110, ticket provider 150, or 
some other source of ticket 240. 

In step 660, after determining that participant 120 has turnstile 230 and 
ticket 240, turnstile 230 may direct participant 120 to access a multicast source 
associated with event 220. In a preferred embodiment of the present invention, this 
1 0 access launches an event renderer thereby initiating delivery of event 220. 

Logging Delivery of Event 

Director server 410 also logs delivery of event 220. In particular, director 
server 410 collects log information from each participant manager 130 and 
mediates them, preferably into an XML file referred to as a Content Delivery Log, 

1 5 for each event 220 delivered. Content Delivery Log includes information 

associated with the delivery of event 220 to each participant 120. Preferably, this 
information includes an event identification, a ticket identification, a user 
identification for billing, a time on event, a time off event, a duration of event, and 
a reason for leaving event {e.g., system failure, voluntary departure, etc.). Other 

20 information may be included in the Content Delivery Log as would be apparent. 
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Reporting on Delivery of Event 

Director server 410 also provides various reports regarding event 220 to 
either system operators (e.g., stadium owners) or content providers 1 10. As would 
be apparent, various reports may be generated from data and delivery statistics 
5 associated with event 220, stadium 210, participants 120, participant managers 
130, and/or content provider 110. 

For example, one such report may provide information regarding ticket 
allocation with respect to a particular content provider 110 operating multiple 
events 220 in stadium 210. This report may provide: a number of tickets available 
10 to be distributed for all future events; a number of tickets allocated for current or 
pending events; a number of tickets to past or current events that were allocated 
but not dispensed to participants; a number of tickets that were dispensed to and 
actually used by participants; and a number of tickets that were dispensed to but 
not used by participants. 

15 Another report may provide post-event information on the allocation of 

tickets to an individual event with the stadium. This report may provide: a 
number of tickets that were allocated to the event but were not dispensed; the 
number of tickets that were dispensed to and used by participants; and the number 
of tickets that were dispensed to but not used by participants. 

20 Another report may provide pre-event information on the number of tickets 

that have been allocated and dispensed for a single event within a particular 
geographic region within the domain of a particular participant manager). 
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Still another report may provide pre-event statistics on the number of tickets that 
have been allocated and dispensed for all events within a particular geographic 
region. 

Yet still another report may provide post-event information on the number 
5 of participants that actually used their ticket to participate in the event by 

geographic region. Another report may provide post-event information on the 
duration of participation for each participant by geographic region. Still another 
report may provide a number of tickets allocated and used based on the 
classification of the ticket 

1 0 Various other reports may be generated including summary reports 

including any or all of the aforementioned reports as would be apparent. 

Tickets 

Tickets 240 provide a mechanism in multicast environment 100 for 
identifying, authenticating, measuring, and controlling participants 120 
15 participating in events 220 within stadium 210. Each ticket 240 includes a unique 
identifier, preferably encrypted by itself or with other information, that is used to 
authenticate ticket 240, to provide security to event 220, and to associate any 
demographic or other participant information gathered by the system. 

Tickets 240 may be of different types including, but not limited to, a single 
20 event ticket, a multi-event ticket (e.g. , a season ticket), a time-based ticket (e.g. , a 
three day pass), or a subscription ticket (e.g. weekly or monthly access). Different 
types of tickets 240 may specify different manners of delivery such as delivery at a 
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regularly scheduled time versus delivery "on demand". Different types of tickets 
240 may also specify one or more different classes of service (e.g. gold or platinum 
levels). 

In a preferred embodiment of the present invention, ticket 240 includes first 
5 authentication information and second authentication information. First 

authentication is used by turnstile 230 to locally determine whether ticket 240 is a 
valid ticket (z.e., one provided by director server 410). Second authentication is 
used by participant managers 130 to actually authenticate that ticket 240 was 
provided to the particular participant 120 in possession of ticket 240. Ticket 240 
10 may also include information associated with participant 120, information 
regarding a class of service, an address of participant managers 130 to which 
turnstile 230 should attach, and/or an address associated with advertising 
information to be provided to participant 120 during event 220. 

As described above, in order for a participant 120 to participate in a 
15 particular event 220, participant 120 must acquire a ticket 240 to the particular 
event 220. Ticket 240 may be acquired at various locations within multicast 
environment 100 including ticket provider 150, content provider 110, and/or 
stadium 210. Ticket 240 may be acquired "in advance" or "at the door." 
Preferably, tickets 240 are acquired at a director server 410 associated with 
20 stadium 210 hosting event 220. Alternately, any of these locations may direct 
participant 120 to a single source of tickets 240 such as ticket provider 150. 
According to the present invention, ticket provider 150 includes any source of 
tickets 240 including commercial tc bricks and mortar" sources. 
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Participant 120 may acquire a ticket 240 in various manners. In one 
embodiment of the present invention, participant 120 acquires ticket 240 by 
providing various demographic or survey information associated with participant 
120. In exchange for this information, ticket provider 150 provides participant 120 
5 with ticket 240. 

In an alternate embodiment of the present invention, participant 120 
acquires ticket 240 by providing payment information in exchange for ticket 240. 
Payment information may include billing information or an actual form of 
monetary compensation (e.gr., cash, e-currency, etc.). In another embodiment of 

10 the present invention, participant 120 acquires ticket 240 by providing both 
demographic information and payment information. In this embodiment of the 
present invention, the payment information may entitle participant 120 to a higher 
class of service over those participants 120 only providing demographic 
information. In some embodiments of the present invention, ticket 240 is 

1 5 distributed to participant 1 20 with no payment information or demographic 
information required. 

Turnstile 

Turnstile 230 functions as a gatekeeper to stadium 210 and event 220. 
Only those participants 120 with an appropriate ticket 240 are allowed to enter 
20 stadium 2 1 0 and participate in event 220. 

In a preferred embodiment of the present invention, turnstile 230 operates 
as an interface between participant 120 and content provider 1 10 (or other source 
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of event 220). Turnstile 230 also operates as an interface between participant 120 
and participant manager 130. Preferably, turnstile 230 is a plug-in (or similar code 
portion) that is downloaded from director server 410 and installed at participant 
120. 

5 FIG, 8 illustrates a relationship among participants 120, turnstiles 230, 

participant managers 130, and content providers 1 10. As illustrated in FIG. 8, 
participants 120 receive event 220 from content provider 110 via a multicast- 
enabled network communication system 105 (illustrated as solid lines in FIG .8). 
Turnstiles 230, resident at each participant 120 monitor the delivery of event 220 
10 and communicate delivery statistics upstream through a hierarchy 300 of 

participant managers 130 to director 140 via a separate protocol layer on network 
communication system 105 referred as a LEAP protocol (illustrated as dashed lines 
in FIG .8). 

Turnstile 230 identifies, authenticates, classifies, and controls participants 
15 120 and their ability to access events 220. Turnstile 230 also monitors use by 

measuring a duration of time participant 120 accessed event 220 and/or an amount 
of data participant 120 received from event 220. 

LEAP Protocol 

The LEAP protocol implements a signaling and transport protocol for 
20 managing events 220 in stadium 210. The LEAP protocol is a light-weight 
transaction protocol built on top of a User Datagram Protocol ("UDP"). The 
LEAP protocol enables unicast as well as multicast transactions. Most transactions 
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within the LEAP protocol are reliable transactions. That is, each transaction is 
verified as successful or failed. This may be accomplished in various manners as 
would be apparent. 

The LEAP facilitates many of the communications between components of 
5 multicast environment 100. More particularly, the LEAP protocol operates on 
turnstile 230, participant managers 130, and director server 410 to provide 
autodiscovery, self-organization, and communication among these components. 

For example, turnstile 230, equipped with ticket 240, notifies multicast 
environment 100 of its desire to participate in event 220 by sending a "JOIN" 

10 message within the LEAP protocol to a particular participant manager 130 
identified in ticket 240. The particular participant manager 130 determines 
whether ticket 240 is valid. If ticket 240 is a valid ticket, participant manager 130 
responds with a "JOIN REPLY" message within the LEAP protocol indicating a 
successful joining of participant 120 to event 220. If ticket 240 is an invalid ticket, 

15 participant manager 130 responds with a JOIN REPLY message indicating that the 
joining failed and participant 120 is unable to gain access to event 220. When 
participant 120 leaves event 220, turnstile 230 sends a "LEAVE" message to the 
particular participant manager 130. Participant manager 130 responds with a 
"LEAVE ACKNOWLEDGEMENT" message. 

20 The LEAP protocol is also used between and among participant managers 

130 for various communications. A lower level participant manager 130 (also 
referred to as a "downstream" participant manager 130) associates itself with a 
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higher level participant manager 130 (also referred to as an Upstream'* participant 
manager 130) by sending an "ATTACH" message within the LEAP protocol to the 
upstream participant manager 130. The upstream participant manager 130 
responds by sending an "ATTACH ACKNOWLEDGEMENT" message within the 
5 LEAP protocol to the lower level participant manager 130. Similarly, a participant 
manager 130 disassociates itself with another participant manager 130 by sending a 
CC DETACH" message within the LEAP protocol. The participant manager 130 
being disassociated responds by sending a "DETACH ACKNOWLEDGEMENT' 
message within the LEAP protocol. 

10 Data is exchanged between components by using a "DATA" message. A 

requestor sends the "DATA" message to a requestee for data. The requestee 
responds with the requested data in a "REPLY" message back to the requestor. 
Many information exchanges are used in multicast environment 100. Examples of 
these include: director server 410 requesting that a particular participant manager 

15 130 provide a list of all participants 1 20 attached to it; a downstream participant 
manager 130 requests that an upstream participant manager provide a list of all 
events 220 it has defined; and a participant manager 130 requests that a particular 
participant 120 provide statistics about itself. 

Some information exchanges in the LEAP protocol are not transactions but 
20 controlled messages that flow upstream. These messages flow upstream at some 
requested configurable rate from a downstream entity such as a participant 120 or 
lower level participant manager 130 to a upstream entity such as a higher level 
participant manager 130 or director server 410. Examples of these messages 
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include: aggregate participant statistic messages, dynamic topology messages 
indicating changes in hierarchy 300, and event specific statistic messages. 

Another type of information exchange in the LEAP protocol are referred to 
as casts. Casts are multicast transactions where the REPLY messages are 

5 aggregated to indicate success or failure of the cast FIG. 9 illustrates a participant 
manager hierarchy 900 operating with a cast transaction. Hierarchy includes a root 
participant manager 910, one or more internal participant managers 920, and one 
or more edge participant managers 930. Root participant manager 91 0 is the 
highest level participant manager in hierarchy 900. Internal participant managers 

10 920 represent one or more levels of mid-level participant managers. Edge 
participant managers 930 represent the lowest level participant managers in 
hierarchy 900. Attached to edge participant managers 930 are participants 120. 

In the cast transaction, root participant manager 910 multicasts a 'DATA" 
message to all other participant managers in hierarchy 900. Edge participant 

1 5 managers 930 that received the multicasted DATA message respond by sending an 
affirmative "REPLY" message upstream, in this example, to one or internal 
participant managers 920. Thus, if edge participant manager 930B receives the 
multicasted DATA message, it sends an affirmative "REPLY" message to internal 
participant manager 920A. Similarly, if edge participant manager 930F receives 

20 the multicasted DATA message, it sends an affirmative "REPLY" message to 
internal participant manager 920B. 
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Internal participant managers 920 only respond to the multicasted DATA 
message if and when all their downstream participant managers have responded. 
In this example, internal participant manager 920A sends an affirmative "REPLY" 
message to root participant manager 910 only after receiving affirmative REPLY 
5 messages from each of participant managers 930A-C. Likewise, internal 
participant manager 920B sends an affirmative "REPLY" message to root 
participant manager 910 only after receiving affirmative REPLY messages from 
each of participant managers 930D-F. The cast transaction is complete when a 
REPLY message has been received from all participant managers* 

10 In the event that some participant managers fail to receive the initial DATA 

message, the cast fails, preferably via a timeout waiting on the REPLY message. 
In a preferred embodiment of the present invention, a localized retransmission of 
the DATA message is sent, hi other words, an upstream participant manager that 
received the DATA message and that has not received a REPLY from a 

1 5 downstream participant manager sends the DATA message directly to that 
downstream participant manager. 

Autodiscovery Algorithm 

According to the present invention, participant managers 130 form 
themselves into hierarchy 300 using an autodiscovery algorithm 1000 illustrated in 
20 FIG. 10 and FIG. 17. Autodiscovery algorithm defines the process by which 

participant managers 1 30 discover their relationships to other participant managers 
in hierarchy 300. 
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Before discussing the algorithm itself, some characteristics of participant 
managers 130 are briefly described. Each participant manager 130 is assigned a 
level within hierarchy 300. As discussed above, this level preferably varies 
between 0 (the lowest level) and 255 (the highest level). These levels are assigned '. 

5 during system design and implementation so that the lowest level participant 
managers 130 preferably reside near participants 130 both logically (in terms of 
network address or number of "hops") and geographically (in terms of physical 
location). Higher level participant managers 130 are similarly organized around 
the lower level participant managers 130. One example of such organization was 

10 described above with respect to FIG. 3. 

Each participant manager 130 is likewise assigned a network address. 
While it would seem simple to merely arrange hierarchy 300 by having various 
lower level participant managers 130 report directly to a particular higher level 
participant manager 130 via this address, such an arrangement does not provide the 

15 self-organizing or self-healing features of the present invention. For example, if 
the particular higher level participant manager 130 fails, the lower level participant 
managers 1 30 assigned to it have no mechanism for reestablishing themselves in 
hierarchy 300. Similarly, the addition of a new participant manager 1 30 to 
hierarchy 300 would require that at least some of the lower level participant 

20 managers 1 30 be manually reassigned. 

Autodiscovery algorithm 1000 however, provides both self-organizing and 
self-healing features by allowing participant managers 1 30 to locate one another 
and arrange themselves in hierarchy 300. A preferred embodiment of 
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autodiscovery algorithm 1000 with respect to a new participant manager 130 
joining hierarchy 300 is now described with reference to FIG. 10. 

In a step 1010, the new participant manager 130 casts an "ANNOUNCE" 
message on a multicast address within multicast environment 100. Preferably, this 

5 multicast address is associated with a particular stadium 210 to which the new 
participant manager 130 is assigned The new participant manager 130 is "new" in 
the sense that it is not yet a member of hierarchy 300 and is desirous of discovering 
its place therein. The ANNOUNCE message includes a unicast address and a level 
associated with the new participant manager 130 to which other participant 

10 managers 130 should respond. 

In a step 1020, the new participant manager 130 receives an "ANNOUNCE 
ACKNOWLEDGE" message from a replying participant manager 130. The 
ANNOUNCE ACKNOWLEDGE message includes a unicast address and a level 
associated with the replying participant manager 130. 

15 In a step 1030, the new participant manager 130 determines whether the 

level of the replying participant manager 130 is less than its own level. If so, the 
response is ignored, and processing continues at step 1020 to evaluate responses 
from other participant managers 130. Otherwise, processing continues at a step 
1040. 

20 In step 1040, the new participant manager 130 determines whether the level 

of the replying participant manager 130 is greater than the level of an upstream 
participant manager 130 that the new participant manager 130 believes is the next 



-36- 



WO 01/89150 PCTYUS01/16156 

higher level above his. This participant manager 130 is referred to as a current 
upstream participant manager and identifies the participant manager 130 to which 
the new participant manager is attached in hierarchy 300. If the level of the 
replying participant manager 130 is greater than the level of the current upstream 
5 participant manager, then the response is ignored, and processing continues at step 
1020 to evaluate responses from other participant managers 130. Otherwise, 
processing continues at a step 1050. 

In step 1050, the new participant manager 130 determines whether the level 
of the replying participant manager 130 is less than the level of the current 

1 0 upstream participant manager 130. If so, processing continues at a step 1 070. Step 
1070 is arrived at when the replying participant manager 130 has a level in 
between that of the new participant manager 130 and that of the current participant 
manager 130. This would indicate that the replying participant manager 130 
should be identified as the current participant manager 130, In step 1070, the 

1 5 replying participant manager is identified as the current participant manager 130. 
In a preferred embodiment, this is accomplished by sending an ATTACH message 
to the replying participant manager 130 and a DETACH message to the current 
participant manager 130. Once step 1070 is completed, processing continues at 
step 1020 to evaluate responses from other participant managers 130. 

20 If in step 1050 the level of the replying participant manager 130 is not less 

than the level of the current upstream participant manager 130, processing 
continues at a step 1060. Step 1060 is arrived at when the level of the replying 
participant manager 130 and that of the current upstream participant manager 130 
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are the same. When this occurs, the new participant manager 130 preferably 
attaches itself to the closest of the two same level participant managers 130. In 
step 1060, the new participant manager 130 determines whether the replying 
participant manager 1 30 is closer than the current upstream participant manager 

5 130. This may be accomplished by determining a number of hops between the 
new participant manager and each of the same level participant managers assuming 
that participant managers with fewer hops between one another are located 
physically closer to one another than those with more hops. Ties in the number of 
hops are resolved in favor of the participant manager with the closest network 

10 address. 

In step 1060, if the replying participant manager 130 is closer than the 
current upstream participant manager, then processing continues at step 1070 
where the replying participant manager is identified as the current participant 
manager as described above. Otherwise, processing continues at step 1020 to 
15 evaluate responses from other participant managers 130. Autodiscovery algorithm 
1000 is repeated until the new participant manager no longer receives further 
ANNOUNCE ACKNOWLEDGE messages. This portion of autodiscovery 
algorithm 1000 establishes the upstream connections of the new participant 
manager 1 30 within hierarchy 300. 

20 FIG. 17 illustrates autodiscovery algorithm 1000 from the perspective of a 

participant manager 130 already existing in hierarchy 130. This portion of 
autodiscovery algorithm 1000 now described establishes the downstream 
connections of the new participant manager 130 within hierarchy 300. 
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In a step 1710, an existing participant manager 130 receives an 
ANNOUNCE message from the new participant manager 130. The participant 
manager 130 is "existing'* in the sense that it is already attached in hierarchy 300. 
In a step 1720, the existing participant manager 130 determines whether the level 
5 of the new participant manager 130 is less than its own level. If so, in a step 1720, 
the existing participant manager 130 responds by sending an ANNOUNCE 
ACKNOWLEDGEMENT message as discussed above. Otherwise processing 
continues at a step 1 740. 

In step 1740, the existing participant manager 130 determines whether the 
10 level of the new participant manager 130 is less than the level of the cuirent 

upstream participant manager 130. If so, the new participant manager 130 is closer 
than the current upstream participant manager 130, and processing continues at a 
step 1750. Otherwise, the ANNOUNCE message from the new participant 
manager 130 is ignored. 

15 In step 1 750, because the new participant manager 130 is closer than the 

current upstream participant manager 130, the existing participant manager 130 
detaches from the current upstream participant manager 130. In a step 1760, the 
existing participant manager 130 restarts autodiscovery algorithm 1000 by casting 
an ANNOUNCE message in step 101 0. 

20 As an example, hierarchy 300 may be obtained using autodiscovery 

algorithm 1000 with the following levels assigned to each of the components: for 
director 140, LEVEL = 255; for West Coast participant manager 310, LEVEL = 
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200; for California participant manager 320A, Oregon participant manager 320B, 
and Washington participant manager 320C, LEVEL = 150; for Central California 
participant manager 330, LEVEL = 80; for San Francisco participant manager 
340A, San Jose participant manager 340B, and Oakland participant manager 340C, 
5 LEVEL = 20; and for participants 350, LEVEL = 0. 

System Operation 

The operation of multicast environment is now described from a 
perspective of each of the following components: participant 120, turnstile 230, 
participant manager 130, director server 410, and finally, director client 420. 

1 0 Participant's Perspective 

FIG. 11 illustrates an operation 1100 of multicast environment 100 from a 
perspective of a participant 120 according to one embodiment of the present 
invention. Ia a step 1110, participant 120 preferably selects an event 220 from 
either a web page provided by content provider 1 10 or from stadium 210. In 
15 alternate embodiments, participant 120 may be delivered a link to event 220 via an 
e-mail, a URL address or other mechanism. 

In a step 1 120, after selecting event 220, director server 410 determines 
whether participant 120 has turnstile 230 installed. In a preferred embodiment of 
the present invention, this accomplished using the SURL delivery method as 
20 described above. If the SURL determines ttattunistt^ 

continues at a step 1 140. Otherwise, in a step 1 130, participant 120 receives a 
turnstile 230 from director server 410. 
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In step 1 140, in one embodiment, turnstile 230 determines whether 
participant 120 has a valid ticket 240 to event 220. In an alternate embodiment, the 
SURL determines if participant 120 has a valid ticket 240 to event 220. If turnstile 
230 determines that participant 120 has a valid ticket, processing continues at a 
5 step 1 160. Otherwise, in a step 1 150, participant 120 acquires a ticket 240 to event 
220. In a preferred embodiment of the present invention, turnstile 230 directs 
participant 120 to a location where participant 120 may acquire ticket 240. 

In step 1 160, participant 120 accesses event 220, or more particularly, 
accesses a multicast address associated with event 220 as provided by the SURL 
10 delivery method from director server 410. This access initiates delivery of event 
220. In a step 1 170, this access invokes turnstile 230 at participant 120 if not 
already invoked. In a step 1 1 80, this access also preferably launches an event 
renderer at participant 120. 

In a step 1 190, participant's 120 participation in event 220 ends. In one 
1 5 embodiment of the present invention, participant 120 closes the event renderer 

thereby ending participation in event 220. Alternately, the delivery of event 220 is 
completed thereby ending participation in event 220. 

Turnstile 's Perspective 

FIG. 12 illustrates an operation 1200 of multicast environment 100 from a 
20 perspective of turnstile 230 according to the present invention. In a step 1210, 
turnstile 230 is installed onto participant 120. 
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In a step 1220, turnstile 230 is invoked when participant 120 accesses event 
220. In a first one embodiment of the present invention, turnstile 230 is invoked 
when participant 120 attempts to access a multicast address associated with event 
220. In this embodiment, turnstile 230 prohibits participant 120 from joining the 
5 multicast until various requirements (e.g. authorization from participant manager 
130) are met. 

In a second embodiment of the present invention, turnstile 230 is a wrapper 
(e.g., Java applet) around the event renderer that intercepts signaling to the event 
renderer thereby prohibiting its launch, until the various requirements are met 

10 In a step 1230, turnstile 230 locates its corresponding participant manager 

130 in hierarchy 300. In one embodiment of the present invention, turnstile 230 
invokes autodiscovery algorithm 1000 as described above to seek out its 
corresponding participant manager. In an alternate embodiment of the present 
invention, turnstile 230 determines an address to its corresponding participant 

15 manager 130 from ticket 240. In yet another alternate embodiment of the present 
invention, turnstile 230 is pre-assigned an address of the corresponding participant 
manager 130. 

Once located in hierarchy 300, in a step 1235, turnstile 230 determines if 
participant 120 has a valid ticket 240. If not, in a step 1260, turnstile 230 directs 
20 participant 1 20 to ticket provider 1 50. Otherwise, processing continues at a step 
1240. 
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In step 1240, turnstile 230 forwards ticket 240 corresponding to event 220 
to participant manager 130. In a preferred embodiment of the present invention, 
turnstile 230 forwards ticket 240 to participant manager 130 in conjunction with a 
JOIN message to participant manager 130. 

5 In a step 1250, turnstile 230 receives a message from participant manager 

130 indicating whether participant 120 has authorization to participate in event 
220. Preferably, this is accomplished by receiving a JOIN REPLY message from 
participant manager 130. If the message from participant manager 130 indicates 
that participant 120 has authorization to participate in event 220, processing 

10 continues at a step 1270. Otherwise, in step 1260, turnstile 230 directs participant 
120 to ticket provider 1 50 where ticket 240 can be acquired. 

In step 1270, the event renderer at participant 120 is launched as discussed 
above to render event 220. In a step 1280, turnstile 230 directs the event renderer 
to a source of the information stream associated with event 220, from which the 
1 5 event renderer collects the information stream and renders ii for participant 120. 

In a step 1290, turnstile 230 periodically gathers delivery statistics 
associated with the delivery of event 220 to participant 120 and forwards them to 
participant manager 130. In one embodiment, turnstile 230 gathers and forwards 
delivery statistics at a start and end of event 220. In another embodiment, turnstile 
20 230 gathers and forwards delivery statistic at a particular rate (e.g. once every two 
seconds). In yet another embodiment, turnstile 230 gathers and forwards delivery 
statistics when queried by director server 410 or one of participant managers 130. 
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Participant Manager's Perspective 

FIG. 13 illustrates an operation 1300 of multicast environment 100 from a 
perspective of participant manager 130 according to the present invention. 

In a step 1310, participant manager 130 locates itself with hierarchy 300. 
5 Preferably, participant manager 130 does so using autodiscovery algorithm 100 as 
described above. Once so located, at some point in time, participant manager 1 30 
receives a ticket 240 from turnstile 230 accompanied by a request to authenticate 
ticket 240. 

In a step 1330, participant manager 130 attempts to authenticate ticket 240. 
10 As discussed above, participant manager 130 uses second authentication 
information included in ticket 240 to verify that ticket 240 was provided to 
participant 120. In a step 1340, participant manager 130 notifies turnstile 230 of 
the results of the authentication. 

In a step 1350, participant manager 130 collects delivery statistics from 
15 turnstile 230. Preferably, participant manager 130 collects delivery statistics from 
each of turnstiles 230 below it in hierarchy 300. In a step 1360, participant 
manager 130 aggregates the delivery statistics from each of turnstiles 230. In a 
step 1370, participant manager 130 forwards the aggregated delivery statistics to 
the upstream participant manager 130. Preferably, each level of participant 
20 managers 130 aggregate the delivery statistics so that they are correlated from root 
to leaf at any point in time within hierarchy 300. 
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For example, San Francisco participant manager 340A aggregates delivery 
statistics from participants 350A-C and forwards them to Central California 
participant manager 330. Similarly, Central California participant manager 310 
aggregates delivery statistics from San Francisco participant manager 340A, San 

5 Jose participant manager 340B, and Oakland participant manager 340C and 
forwards them to California participant manager 320A. Each higher level 
participant manager 130 aggregates and forwards delivery statistics from those 
participant managers immediately beneath it until director server 410 receives the 
aggregated delivery statistics representing all participants 120 of a particular event 

10 220. 

The delivery statistics may include: an identification of event 220, an 
identification of participant manager 130 forwarding the statistics, a number of 
participants 120 directly attached to the participant manager 130, and an aggregate 
number of participants 120 indirectly attached to the participant manager 130 
15 through lower level participant managers 130. Delivery statistics may also include 
a time a particular participant 120 joined particular event 220, and/or a time the 
particular participant 120 left the particular event 220 

Director Server's Perspective 

FIG. 14 illustrates an operation 1400 of multicast environment 100 from a 

20 perspective of director server 410 according to the present invention. After 

« 

director server 4 1 0 is installed and started, in a step 1410, director server 410 
locates the highest level participant managers 130 in hierarchy 300. In one 
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embodiment of the present invention, director server 410 locates the highest level 
participant managers 130 using autodiscovery algorithm 1000. For example, as 
illustrated in FIG. 3, director 140 (Le. 9 director server portion 410) discovers West 
Coast participant manager 310 as well as any other participant managers 130 
5 sharing the same level (not illustrated). In another embodiment of the present 
invention, director server 410 knows ahead of time the address of the highest level 
participant managers 130. 

In a step 1420, content provider 110 creates event 220 at director server 
410 using director client 420. In a step 1425, director server 41 0 creates and 

10 allocates tickets 240 for event 220. In a preferred embodiment of the present 
invention, creating event 220 includes describing all properties of event 220 
including, but not limited to, advertisements associated with event 220 and to the 
provisioning of tickets 240 for event 220. In a step 1430, director server 410 
notifies its participant managers 130 of event 220. In particular, director server 

15 410 preferably supplies its participant managers 130 with an identification of event 
220, a duration of event 220, and a duration during which participants 120 are 
allowed to join. In a step 1440, director server 410 provides a ticket 240 to 
participant 120 to access event 220. 

In a step 1450, director server 410 periodically receives delivery statistics 
20 associated with event 220 from its participant managers 130. In a step 1460, 
director server 410 logs these delivery statistics as discussed above. In a step 
1470, director server 410 provides director client 420 with the delivery statistics so 
that content provider 1 10 or a system operator can view the delivery statistics. 
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FIG. 15 illustrates an operation 1500 of director server 410 responding to a 
query from director client 420 with respect to delivery statistics associated with a 
particular participant manager 130 in hierarchy 300. In a step 1510, director server 
410 receives a request from director client 420 regarding the delivery statistics 
5 associated with one of participant managers 130 in hierarchy 300. Preferably, this 
request can be made for any of participant managers 310, 320, 330, and 340, or 
participants 350 in hierarchy 300. 

hi a step 1520, director server 410 queries the particular participant 
manager 130 directly. In a step 1530, director server 410 receives delivery 
1 0 statistics directly from the queried participant manager 130. In a step 1 540, 
director server 41 0 provides director cheat 420 with the requested delivery 
statistics associated with the particular participant manager 130 in hierarchy 300. 

Director Client's Perspective 

FIG. 16 illustrates an operation 1600 of multicast environment 100 from a 
15 perspective of director client 420 according to the present invention. Operation 
1600 is now described with reference to FIG. 5. 

In a step 1610, after being installed at a user (i.e., either content provider 
1 10 or a system operator) director client 420 requests information regarding 
hierarchy 300 and delivery statistics associated therewith for a particular event 220 
20 from director server 410. In a step 1620, director client 420 receives the requested 
information from director server 410. In a step 1630, director client 420 presents 
the user with a graphic user interface such as GUI 500 illustrated in FIG. 5. 
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Preferably, an initial presentation of hierarchy 300 in GUI 500 includes director 
server 410 and its participant managers 130 the highest level participant 
managers 130 in hierarchy 300 directly connected to director server 410 such as 
West Coast participant manager 310). Furthermore, the aggregated delivery 
5 information associated with event 220 is preferably presented in GUI 500 with 
respect to director server 410 with its constituent components broken down for 
each of participant managers 130. 

In a step 1640, director client 420 receives a request from the user for 
delivery statistics with respect to a particular participant manager 130. In a step 
10 1650, director client 420 forwards the request directly to the particular participant 
manager 130. In a step 1660, the director client 420 receives the requested 
delivery statistics directly from the particular participant manager 130. In a step 
1670, director client 420 presents the user with an updated GUI 500 with the 
delivery statistics for the particular participant manager 130. 

1 5 Director client 420 provides the user with several mechanisms for selecting 

the particular participant manager 130 for which delivery statistics are desired. 
According to one embodiment of the present invention, the user may expand GUI 
tree structure 515 by "clicking on" structure indicators 520, 525. As discussed 
above, the GUI aspect of the present invention operates in a familiar manner to the 

20 "directory structure" of a typical "file manager." In doing so, director client 420 
requests more specific information with respect to each lower level participant 
manager 130 appearing in the expanded GUI tree structure 515. As GUI tree 
structure 515 is expanded further and further, delivery statistics are requested for 

-48- 



WO 01/89150 



PCTYUS01/16156 



each corresponding lower level participant manager 130 until GUI tree structure 
5 1 5 is fully expanded at which time delivery statistics are requested for individual 
participants 120. 

According to one embodiment of the present invention, alone or preferably 
5 in combination with the embodiment just described, the user may also select a 
particular participant manager 130 or participant 120 within GUI tree structure 515 
to obtain delivery statistics for that particular entity as described above. 

Advertising Model 

In one embodiment of the present invention, participants 120 acquire ticket 
1 0 240 at least in part, by providing demographic information to ticket provider 1 50. 
Such demographic information may include, but is not limited to, a name, a 
geographic location, an address, an age, a gender, a household income, an 
occupation, a telephone number, an email address, a product preference, and 
various other demographic or marketing information as would be apparent 

15 According to the present invention, such demographic information is 

gathered by ticket providers 150 and collected at director server 410 and preferably 
organized using an identification of ticket 240 that was issued in exchange for the 
demographic information. This demographic information may be used to provide 
targeted advertising to participants 120 that correspond to a particular demographic 

20 profile. Such a demographic profile may be generated at director client 420 and 
forwarded to director server 410 to obtain a list of participants 120 that match the 
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demographic profile for a particular event 220 or group of events 220 so that a 
particular advertisement may be sent to the list of participants 120. 

In a preferred embodiment, one or more URL addresses are included with 
ticket 240 for delivering advertising information to participant 120 during event 
5 220. One URL address may deliver a "stadium banner" that is delivered to all 
participants of event 220. Another URL address may deliver an advertising stream 
only to those participants 120 of event 220 that match a particular demographic 
profile. 

For example, a particular advertiser may wish to target an advertisement 
10 towards 18-25 year old males living within a particular geographic area (e.g., San 
Francisco) during a particular event or type of event. The advertiser would access 
the present invention through director client 420 to create an appropriate 
demographic profile corresponding to this group of individuals and forward it to 
director server 410. Director server 410 subsequently includes a URL address 
1 5 corresponding to the advertisement in tickets 240 for the particular event 220 or 
type of event provided to participants 120 that the match the advertiser's 
demographic profile. 

While the present invention has been described in terms of a preferred 
embodiment, other embodiments and variations are within the scope of the 
20 following claims. 
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What is claimed is 



1 1 . A system for multicasting an event to a plurality of participants 

2 comprising: 

3 a director having a multicast address associated therewith for delivering the 

4 event to the plurality of participants; 

5 a plurality of participant managers installed within a network 

6 communication system and logically connected amongst themselves and to said 

7 director thereby forming a hierarchy; and 

8 a turnstile installed at and associated with each of the plurality of 

9 participants, each turnstile logically connected to one of said plurality of 
1 0 participant managers in said hierarchy. 

1 2. The system of claim 1, wherein said turnstile sends delivery 

2 statistics regarding said associated participant to said connected participant 

3 manager; and 

4 wherein said plurality of participant managers propagates said delivery 

5 statistics upstream through said hierarchy to said director. 

1 3. The system of claim 2, wherein said plurality of participant 

2 managers aggregates said delivery statistics from those of said plurality of 

3 participants beneath it in said hierarchy. 

1 4. The system of claim 1, wherein said associated participant presents 

2 said turnstile with a ticket to the event to gain access to the event. 

1 5. The system of claim 4, wherein said turnstile determines whether 

2 said ticket is valid. 
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1 6. . The system of claim 5, wherein said turnstile forwards a valid ticket 

2 to said connected participant manager for authentication. 

1 7. The system of claim 6, wherein said connected participant manager 

2 communicates authorization to said turnstile upon determining said ticket is 

3 authentic. 

1 8. The system of claim 1, wherein said director provides event 

2 information to said connected participant manager. 

1 9. The system of claim 1, wherein said turnstile prevents said 

2 associated participant from receiving the event until a ticket associated with the 

3 event is authenticated. 

1 10. The system of claim 1, wherein said turnstile prevents said 

2 associated participant from receiving the event until a ticket associated with the 

3 event is determined to have been provided to said associated participant 

1 1 1 . A method for organizing a plurality of participants and a plurality of 

2 participant managers in a hierarchy under a director comprising: 

3 receiving a message from a sending participant manager at a receiving 

4 participant manager, said sending participant manager and said receiving 

5 participant manager included in the plurality of participant managers, said message 

6 including a level of said sending participant manager; 

7 determining whether said receiving participant manager should be attached 

8 in the hierarchy to said sending participant manager based on said level of said 

9 sending participant manager and a level of said receiving participant manager; and 

10 if so, attaching said receiving participant manager to said sending 

1 1 participant manager thereby forming the hierarchy. 



-52- 



WO 01/89150 



PCT/US01/16156 



1 12. The method of claim 1 1, wherein said determining comprises 

2 determining whether said receiving participant manager should be attached in the 

3 hierarchy to said sending participant manager based on said level of said sending 

4 participant manager, said level of said receiving participant manager, and a level of 

5 an attached participant manager to which said receiving participant manager is 

6 already attached. 



1 13. The method of claim 12, wherein said determining comprises: 

2 detennining whether said level of said sending participant manager is less 

3 than said level of said receiving participant manager. 

1 14. The method of claim 12, wherein said determining comprises: 

2 determining whether said level of said sending participant manager is less 

3 than said level of said receiving participant manager, and 

4 if not, determining whether said level of said sending participant manager 

5 is greater than said level of said attached participant manager. 

1 15. The method of claim 12, wherein said determining comprises: 

2 determining whether said level of said sending participant manager is less 

3 than said level of said receiving participant manager; 

4 if not, determining whether said level of said sending participant manager 

5 is greater than said level of said attached participant manager, and 

6 if not, determining whether said level of said sending participant manager 

7 is less than said level of said attached participant manager. 

1 16. The method of claim 12, wherein said determining comprises: 

2 determining whether said level of said sending participant manager is less 

3 than said level of said receiving participant manager; 

4 if not, determining whether said level of said sending participant manager 

5 is greater than said level of said attached participant manager; 
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6 if not, detennining whether said level of said sending participant manager 

7 is less than said level of said attached participant manager, and 

8 if not, detennining whether said sending participant manager is closer to 

9 said receiving participant manager than said attached participant manager. 

1 17. The method of claim 1 1 , further comprising: 

2 multicasting an announce message to said sending participant manager 

3 from said receiving participant manager. 

1 18. The method of claim 1 7, further comprising: 

2 sending an announce acknowledge message to said receiving participant 

3 manager from said sending participant manager, wherein said message comprises 

4 said announce acknowledge message. 

1 19. The method of claim 18, further comprising: 

2 detennining whether a level of said receiving participant manager is less 

3 than a level of said sending participant manager; and 

4 if so, sending an announce acknowledge message to said receiving 

5 participant from said sending participant manager, wherein said message 

6 comprises said announce acknowledge message. 

1 20. The method of claim 19, further comprising: 

2 if said level of said receiving participant manager is not less than said level 

3 of said sending participant manager, detennining whether said receiving 

4 participant manager is closer to said sending participant manager than a participant 

5 manager to which said sending participant manager is already attached. 

1 21 . The method of claim 20, further comprising: 

2 detaching said sending participant manager from said attached participant 

3 manager; and 

4 multicasting an announce message from said sending participant manager. 
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1 22. A method for gating a participant access to a multicasted event 

2 comprising: 

3 upon the participant attempting to access the event, prohibiting the 

4 participant from joining the event; 

5 determining whether the participant has a ticket; 

6 if the participant has a ticket, determining whether said ticket is a valid 

7 ticket; 

8 if the participant has a valid ticket, receiving information as to whether said 

9 ticket is an authentic ticket; 

10 . if the participant has an authentic ticket, allowing the participant to join the 

11 event 

1 23. The method of claim 22, wherein said prohibiting comprises 

2 intercepting an attempt by an event renderer located at the participant to join the 

3 event 

1 24. The method of claim 22, wherein said prohibiting comprises 

2 preventing an event renderer located at the participant from launching. 

1 25. The method of claim 22, wherein said allowing comprises allowing 

2 said event renderer to join the event. 

1 26. The method of claim 24, wherein said allowing comprises allowing 

2 said event renderer to launch. 

1 27. The method of claim 22, further comprising directing the participant 

2 to a ticket provider if the participant does not have a ticket 
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1 28. The method of claim 22, further comprising directing the participant 

2 to a ticket provider if the participant does not have a valid ticket. 

1 29. The method of claim 22, further comprising directing the participant 

2 to a ticket provider if the participant does not have an authentic ticket 

1 30. The method of claim 22, further comprising attaching the 

2 participant to a director through a hierarchy of participant managers. 

1 31. The method of claim 30, wherein said step of receiving information 

2 as to whether said ticket is an authentic ticket comprises receiving said information 

3 from said hierarchy. 

1 32. The method of claim 30, wherein said step of receiving information 

2 as to whether said ticket is an authentic ticket comprises receiving said information 

3 from a participant manager in said hierarchy to which the participant is attached.. 

1 33. The method of claim 30, further comprising notifying said director 

2 that the participant joined the event. 

1 34. The method of claim 30, further comprising notifying said director 

2 that the event ended. 

1 35. The method of claim 30, further comprising notifying a participant 

2 manager in said hierarchy to which the participant is attached that the participant 

3 joined the event. 

1 36. A method for multicasting an event to a plurality of participants 

2 comprising: 
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3 detennining whether a participant has a turnstile installed in response to a 

4 request by said participant to participate in the event; 

5 detennining whether said participant has a valid ticket to the event; 

6 directing said participant to a multicast source that delivers the event; 

7 notifying a director that said participant has joined the event; and 

8 monitoring the delivery of the event 

1 37. The method of claim 36, further comprising installing said turnstile 

2 at said participant. 

1 38. The method of claim 36, further comprising providing said valid 

2 ticket to said participant. 

1 39. The method of claim 36, further comprising notifying said director 

2 when the event ends. 

1 40. The method of claim 39, wherein said notifying comprises notifying 

2 said director upon said participant closing the event 

1 41 . The method of claim 39, wherein said notifying comprises notifying 

2 said director upon completing the delivery of the event. 

1 42. A method for aggregating delivery statistics comprising: 

2 organizing a hierarchy having a lower level and a higher level, said lower 

3 level including a plurality of lower level participant managers, said higher level 

4 including a higher level participant manager, each of said plurality of lower level 

5 participant managers attached to a participant; 

6 receiving delivery statistics from each of said participants at each of said 

7 plurality of lower level participant managers; 
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8 forwarding said received delivery statistics to said higher level participant 

9 manager, and 

10 aggregating said forwarded delivery statistics at said higher level 

11 participant manager, 

1 43. A method for providing a targeted advertisement to a participant of 

2 a multicasted event comprising: 

3 collecting demographic information from the participant; 

4 determining geographic information associated with the participant; 

5 creating a ticket for the participant, said ticket including advertising 

6 information targeted to the participant based on at least one of said demographic 

7 information and said geographic information; 

8 providing said ticket to the participant; and 

9 granting the participant access to the multicasted event using said ticket, 

10 whereby the targeted advertisement is delivered to the participant during 

11 the multicasted event based on said advertising information. 

1 44. The method of claim 43, wherein said advertising information 

2 includes a network address associated with the targeted advertisement. 

1 45. The method of claim 43, wherein said advertising information 

2 includes the targeted advertisement. 

1 46. A tree structure in a graphic user interface comprises: 

2 a first level structure indicator corresponding to and identifying a higher 

3 level participant manager, and 

4 a plurality of second level structure indicators organized under said first 

5 level structure indicators, each of said second level structure indicators 

6 corresponding to and identifying a lower level participant manger, each lower level 
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7 participant manager associated with at least one participant to which an event is 

8 being delivered; 

9 wherein said second level structure indicator includes information 

10 regarding said at least one participant associated with said corresponding lower 

1 1 level participant manager, and 

12 wherein said first level structure indicator includes aggregate information 

1 3 regarding said lower level participant managers. 

1 47. A system for multicasting an event to a plurality of participants 

2 comprising: 

3 a director having a multicast address associated therewith for delivering the 

4 event to the plurality of participants; 

5 a plurality of participant managers installed within a network 

6 communication system and logically connected amongst themselves and to said 

7 director thereby forming a hierarchy organized on a geographic basis; and 

8 a turnstile installed at and associated with each of the plurality of 

9 participants, each turnstile logically connected to one of said plurality of 

10 participant managers in said hierarchy that corresponds to a geographic location of 

11 said associated participant, said turnstile requiring a ticket for said associated 

12 participant to access the event, 

13 wherein said director allocates a non-zero number of tickets to a first 

14 participant manager in said hierarchy and allocates zero tickets to a second 

15 participant manager in said hierarchy thereby restricting access to the event to 

1 6 some of the plurality of participants. 
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